Exemplary references which frame the background of this invention are:
1. C. J. Date, "AN INTRODUCTION TO DATABASE SYSTEMS", Vol. 1, Fourth Edition, Addison Wesley Publishing Company, Copyright 1986, Chapter 18. PA0 2. H. F. Korth, et al, "DATABASE SYSTEM CONCEPTS" McGraw-Hill Book Company, Copyright 1986, Chapter 10. PA0 3. C. Mohan, et al, "ARIES: A TRANSACTION RECOVERY METHOD SUPPORTING FINE-GRANULARITY LOCKING AND PARTIAL ROLLBACKS USING WRITE-AHEAD LOGGING" IBM Research Report RJ 6649 (63960) , Jan. 23, 1989, Revised Nov. 2, 1990. PA0 4. C. Mohan, "COMMIT.sub.-- LSN: A NOVEL AND SIMPLE METHOD FOR REDUCING LOCKING AND LATCHING IN TRANSACTION PROCESSING SYSTEM", Proceedings of the Sixteenth VLDB Conference, August, 1990. PA0 5. C. Mohan, et al, "TRANSACTION MANAGEMENT IN THE R* DISTRIBUTED DATABASE MANAGEMENT SYSTEM", ACM Transactions on Database Systems, Vol. 11, No. 4, December, 1986, pgs. 378-396. PA0 1. Under the no-force policy, transaction updates are recorded in a log, but updated pages are not necessarily written to non-volatile storage when a transaction's commit point is reached. Thus, a failure may occur after updates are recorded on the log but before they are made in non-volatile storage. Thus, a page on disk at restart may not contain some updates for which log records exist. These updates might be ones that were performed by uncommitted and/or committed transactions. Permitting access to such a page might lead to a new transaction reading an older version of a piece of data for which one or more log records written by one or more committed transactions remain to be applied during the REDO phase of restart recovery. Assuming record locking is used with flexible storage management, even if the new transaction were to access the page for updating or inserting some record for which no unapplied log records exists, permitting that operation to complete might result in some space on the page being consumed which results in a state in which it is impossible to redo some of the unapplied changes relating to other records on the same page for which log records exist. Since the REDO phase is page-oriented and not performed logically across pages, the REDO phase must be completed for these pages before new transactions are permitted access to them. PA0 2. A page on disk may contain all the updates logged for that page. However, permitting access to such a page could cause inconsistencies if the page contains updates of in-flight transactions which are to be rolled back during the UNDO phase of restart. The page may also contain updates of in-doubt transactions whose commit or abort outcome will remain doubtful at the end of restart and for which locks will be reacquired during the course of the REDO phase to protect their uncommitted updates. Allowing access during these conditions might result in a new transaction reading some uncommitted data even though the new transaction will be acquiring locks. PA0 uses restart recovery to add to pages the results of logged transaction updates which are missing in the database pages and to rollback uncommitted transactions which were executing at the time of the failure for which no log commit or in-doubt records exist; and PA0 concurrently with operation of the restart recovery, provides for transaction processing data structures whose contents were not changed after the beginning of the earliest-starting uncommitted transaction. PA0 assigns a log sequence number (LSN) to each log record which denotes the log record's position in a log sequence; PA0 enters into each data structure staged into a non-volatile storage an LSN denoting the last update made to the data structure; PA0 operates the recovery restart mechanism in response to a failure in the system; and PA0 during operation of the restart recovery mechanism: PA0 suspends the transaction until restart recovery is completed.
These references cover two-phase, commit-type, transaction-oriented database systems which utilize write-ahead logging to register commitment of updates to database data structures. The Date and Korth references document the inherent features of a recovery mechanism which utilizes a log to reset data resources to a state at which a transaction-based system can resume operation following a failure. The first-cited Mohan reference concerns the use of a log to record the operation of a transaction which updates data objects. The log contains in chronological sequence records of committed updating actions taken by a transaction. In this reference, Mohan critically observed that the assignment of a unique log sequence number (LSN) to every log record such that the LSNs are assigned in ascending sequence provides a powerful and efficient basis for recovery, concurrency control, and buffer management in a database system. In the second-cited Mohan reference, a COMMIT.sub.13 LSN is posited to determine if a data object (such as a page) contains committed updates. Relatedly, each page has recorded on it the LSN of the last update made to it. Equating the COMMIT.sub.13 LSN to the LSN of the first log record of the oldest update transaction still in progress permits a system to infer that all updates in pages with page.sub.13 LSN less than COMMIT.sub.13 LSN have been committed. The last-cited Mohan et al reference is relevant to the state of the art.
In transaction processing, the property of atomicity guarantees that if a transaction executes some updates against a recoverable data resource, and a failure occurs before the transaction reaches its normal termination or an interim point of consistency ("commits"), then those updates will be undone. As Date teaches, atomicity is provided by COMMIT and ABORT operations. The COMMIT operation signifies that a transaction has completed and that all of its updates must be permanently entered into the database. The ABORT operation signifies the unnatural termination of a transaction caused by the occurrence of a fault; it signifies inconsistency of the database and implies that all updates made by the unsuccessfully-completed transaction must be undone ("rolled back").
In the incorporated patent application and in the first-cited Mohan reference, a system failure which interrupts transaction processing initiates operation of a restart recovery mechanism (a "Mohan-type" restart recovery mechanism) including REDO and UNDO components. The REDO component tracks back in the system log from the point of failure to obtain log records whose updates had not been entered into the database, by the time of the failure. Those log records that were written by committed transactions are used to permanently enter those updates into the record. The UNDO component utilizes the log records to track back from the point of failure all transactions which were unnaturally terminated by the failure and rolls those transactions back.
Relatedly, transactions with uncommitted updates which are terminated by a system failure are referred to as "in flight" transactions.
The Mohan-type restart recovery mechanism also processes transactions which have had updates committed but which have not naturally ended at the point of failure. These transactions are referred to as "in doubt" transactions and are either redone or undone according to conditions which exist at the time of recovery.
Various solutions have been proposed to provide improved data availability during restart recovery. One of the solutions is system redundancy in which the failure of one system initiates the operation of a redundant standby system. This solution is exemplified, for example, in the XRF (extended recovery facility) of the IMS product available from the assignee. Another solution uses parallel non-volatile memory. See, for example, R. Agrawal et al, "RECOVERY ARCHITECTURES FOR MULTIPROCESSOR DATABASE MACHINES", ACM Reprint 0-89791-160-1/85/005/0131, Copyright 1985. All of these solutions are relatively expensive.
There is, therefore, an evident need for a cost-effective technique which makes data available during restart recovery processing in a database management system. This need is particularly critical in view of the possibility that recovery may entail undoing very long transactions by a single process in which all read I/Os are performed synchronously, one page at a time. The desired solution should be one which supports beneficial features of a DBMS such as fine-granularity locking with semantically-rich lock modes and operation logging, partial rollbacks, write-ahead logging, as well as steal and no-force buffer management policies. A force buffer management policy states that before a transaction is allowed to commit, all data structures modified by the transition must be forced to non-volatile storage. The steal policy states that a page with uncommitted updates may be written to non-volatile storage.